
United States Patent and Trademark Office 



UNITED STATES DEPARTMENT OF COMMERCE 
United States Patent and Trademark Office 
Address: COMMISSIONER FOR PATENTS 
P.O. Box 1450 

Alexandria, Virginia 22313-1450 
www.uspto.gov 



APPLICATION NO. 


FILING DATE 


FIRST NAMED INVENTOR 


ATTORNEY DOCKET NO. 


CONFIRMATION NO. 1 


09/500,391 


02/08/2000 


Wei- Ping Sun 


CISCO- 1858 


2543 



7590 

David B Ritchie 
D'Alessandra & Ritchie 
P O Box 640640 
San Jose, CA 95164 



12/03/2003 



EXAMINER 



VOLPER, THOMAS E 



ART UNIT 



PAPER NUMBER 



2665 

DATE MAILED: 12/03/2003 



13 



Please find below and/or attached an Office communication concerning this application or proceeding. 



PTO-90C (Rev. 10/03) 



Office Action Summary 



Application No. 



09/500,391 



Examiner 

Thomas Volper 



Applicant(s) 



SUN ET AL 



Art Unit 

2665 



The MAILING DATE of this communication appears on the cover sheet with the correspondence address - 
Period for Reply 

A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH (S) FROM 
THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1.136(a). In no event, however, may a reply be timely filed 
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- Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1 .704(b). 

Status 

I) ^ Responsive to communication(s) filed on 16 September 2003 . 
2a)M This action is FINAL. 2b)Q This action is non-final. 

3) D Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Quayle, 1 935 CD. 1 1 , 453 O.G. 21 3. 

Disposition of Claims 

4) £3 Claim(s) 1-4.6-8, 10-17.37 and 39-48 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

5) D Claim(s) is/are allowed. 

6) |EI Claim(s) 1-4.6-8. 10-17.37 and 39-48 is/are rejected. 

7) D Claim(s) is/are objected to. 

8) D Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) D The specification is objected to by the Examiner. 

10)D The drawing(s) filed on is/are: a)D accepted or b)D objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1 .85(a). 
Replacement drawing sheet(s) including the correction is required if the drawing(s) is objected to. See 37 CFR 1.121(d). 

II) D The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-152. 
Priority under 35 U.S.C. §§119 and 120 

12) D Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 119(a)-(d) or (0. 

a)[ZI All b)D Some*c)D None of: 

1 .□ Certified copies of the priority documents have been received. 

2. Q Certified copies of the priority documents have been received in Application No. . 

3. Q Copies of the certified copies of the priority documents have been received in this National Stage 

application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 

13) D Acknowledgment is made of a claim for domestic priority under 35 U.S.C. § 119(e) (to a provisional application) 

since a specific reference was included in the first sentence of the specification or in an Application Data Sheet. 
37 CFR 1.78. 

a) □ The translation of the foreign language provisional application has been received. 

14) D Acknowledgment is made of a claim for domestic priority under 35 U.S.C. §§ 120 and/or 121 since a specific 

reference was included in the first sentence of the specification or in an Application Data Sheet. 37 CFR 1 .78. 
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DETAILED ACTION 

Response to Arguments 

1 . Applicant's arguments with respect to claims 1, 16, 37 and 41 have been considered but 
are moot in view of the new ground(s) of rejection. 

Claim Rejections - 35 USC § 103 

2. The following is a* quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

3. Claims 1-4, 6-8, 10-17, 37 and 39-48 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Klimenko (US Pat. 5,974,547) in view of K. R. Soilings, "The TFTP Protocol 
(Revision 2)" (hereinafter RFC 783) and Bailey et al. (US 6, 1 85,623). 

Regarding claims 1, 16, 37, 41, 43 and 46 Klimenko discloses a technique for reliable 
booting of an operating system to a client computer. The client computer contains a LAN 
adapter, also referred to as a network interface card-NIC (col. 7, lines 11-16). This NIC 
represents the router card of the present invention. The server (50) represents the system 
controller of the present invention and the network (30) represents the bus of the present 
invention (see Figure 2A). The client computer will issue a trivial file transfer protocol (TFTP) 
request to server (50) by way of the NIC. The TFTP server locates and opens this file based on 
the information provided in the TFTP request, then downloads this boot file, LANHD.IMG, to 
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the client computer. The PC acknowledges successful download by sending an 
acknowledgement packet to the server (col 1 1, lines 12-26). Klimenko discloses that the server 
provides the name of a file to be accessed to the NIC in a BootP reply packet prior to sending the 
TFTP request packet. This BootP reply packet provides a path, \L ANHD\L ANHD . IMG, which 
contains the name of the image file that the client is to download through the NIC. Klimenko 
fails to expressly disclose that the information used to locate the file is a port address and file 
type, and that the server transmits file size to the NIC. Klimenko also fails to disclose 
performing this process for an inactive router card in addition to an active router card. RFC 783 
discloses a TFTP format for a request packet that includes a filename (section 5). As well known 
in the art, a filename implicitly specifies a file type. For example, in the invention of Klimenko 
the file L ANHD, IMG specifies an image file. RFC 783 also discloses that all TFTP packets 
contain a source port address (see I Appendix). Bailey discloses a system for booting a client 
computer from a server that uses the TFTP. In this system the client may include a transfer size 
request in the TFTP request packet, in which case the server responds to the request packet with 
the transfer size (col. 4, line 58 - col. 5, line 36). The purpose of requesting the transfer size is to 
determine the amount of memory needed to store a file (col. 1 1, lines 57-67). This constitutes 
setting up a buffer size of at least as large as the file size. Bailey also discloses a subnet group of 
clients wherein one client is the master client, representing the active router card of the present 
invention, while any other clients in the group may represent an inactive router card (col. 6, lines 
25-40 and col. 7, lines 35-56). At the time the invention was made, it would have been obvious 
to use the file type and port address to identify the file to be sent to the NIC. It also would have 
been obvious to send the file size to the NIC. It would have been obvious to have a master client 
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and at least one other client that were sending requests to the server of Klimenko in order to 
download an image file. One of ordinary skill in the art would have been motivated to use the 
port address to first locate the directory corresponding to the particular client NIC in the server, 
and the file type, image, to determine which file in the directory to send. One would have been 
motivated to send the file size to the NIC so that the client would be able to set aside enough 
memory to store the image file. One of ordinary skill in the art would have been motivated to 
have a group of clients containing a master client in case the group of clients all needed to 
download the same image file in order to use a common operating system. 

Regarding claims 2 and 17, Klimenko discloses using trivial file transfer protocol (TFTP) 
to make the request for the image file. Klimenko also discloses that a TFTP acknowledgement 
packet is sent to the server when the client successfully downloads the file (col. 1 1, lines 17-22), 
Klimenko fails to expressly disclose forming a data packet from the file, wherein the data packet 
is a fixed size and includes a system frame header and a data packet protocol header. RFC 783 
discloses that TFTP uses packets of fixed length blocks (page 3). Figure 3-1 : Order of Headers 
(page 5) shows a header structure including Local Medium and Internet headers, which 
collectively represent the system frame header of the present invention, and Datagram and TFTP 
headers, which represent the data packet protocol header of the present invention. TFTP also 
specifies that each data packet must be acknowledged by an acknowledgement packet before the 
next packet can be sent (page 3). At the time the invention was made, it would have been 
obvious to a person of ordinary skill in the art to use the fixed size TFTP packet format with the 
appropriate headers in sending data packets formed from the requested file. One of ordinary skill 
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in the art would have been motivated to do this because this protocol is small and easy to 
implement for the purpose of transferring files. 

Regarding claim 3, Klimenko fails to disclose sending a last packet less than the fixed 
size. RFC 783 discloses that a data packet of less than 512 bytes, which is the fixed size, signals 
the termination of a transfer (page 3). At the time the invention was made, it would have been 
obvious to a person of ordinary skill in the art to use this last packet smaller that 512 bytes at the 
end of the file transfer in the invention of Klimenko. One of ordinary skill in the art would have 
been motivated to do this to signal to the NIC that the transfer was complete so that the NIC 
could start using the downloaded file. 

Regarding claim 4, Klimenko fails to disclose retransmitting a data packet to the client if 
the server receives a duplicate acknowledgment packet for the previous packet. RFC 783 
discloses that a lost data packet causes a timeout for the intended recipient, in which case the 
intended recipient retransmits its last packet (page 3). Thus, if the intended recipient is the client 
and a timeout condition occurs, the client would then send an acknowledgement packet for the 
previously received data packet, i.e. a duplicate acknowledgment. At the time the invention was 
made, it would have been obvious to a person of ordinary skill in the art to retransmit a data 
packet formed from the image file of Klimenko in response to receiving a duplicate 
acknowledgement packet. One of ordinary skill in the art would have been motivated to do this 
in order to signal the server that a data packet has not been received and needs to be 
retransmitted. 

Regarding claims 6, 40, 45 and 48, Klimenko does not expressly disclose a system frame 
header and a data packet protocol header consisting essentially of an operation code, a block 
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number, a file type and a checksum. RFC 783 discloses a header structure in Figure 3-1 : Order 
of Headers (page 5) of Local Medium and Internet headers, which represent the system frame 
header of the present invention, and the Datagram and TFTP headers represent the data packet 
protocol header of the present invention. The format for a data packet includes an opcode and a 
block # (see Figure 5-2, page 10). Additionally, TFTP specifies that it may be implemented on 
top of the Internet User Datagram Protocol (UDP or Datagram) (page 2). The User Datagram 
Header includes a checksum (page 15). Thus, this checksum would be included in the data 
packet protocol header. RFC 783 also specifies that a request (RRQ) packet includes a filename 
in the header. This filename represents the file type of the present invention because the file type 
is provided in the filename extension. At the time the invention was made, it would have been 
obvious to a person of ordinary skill in the art to use a system frame header and the data packet 
protocol header format of a TFTP data packet in sending data packets in the invention of 
Klimenko. It also would have been obvious to include the filename, normally only included in 
the TFTP RRQ packet, in the header of the data packet. One of ordinary skill in the art would 
have been motivated to use the system frame header and data packet protocol header to be 
compliant with the TFTP standard. One of ordinary skill in the art would have been motivated to 
include the filename in the TFTP data packet header so that the NIC on the client computer 
would be able to determine which packets belong to which file if more than one file is being 
downloaded. 

Regarding claim 7, Klimenko fails to disclose that the acknowledgement packet consists 
essentially of a system frame header, and acknowledgement code, and a block number. RFC 783 
discloses a format for an ACK packet that contains an opcode, which represents the 
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acknowledgement code, and block # (see Figure 5-3, page 10). The system frame header is 
shown in Figure 3-1 (page 5). At the time the invention was made, it would have been obvious 
to a person of ordinary skill in the art to use this format of an acknowledgement packet in 
acknowledging the received file from the server in the invention of Klimenko. One of ordinary 
skill in the art would have been motivated to do this so that the server would know which packets 
have been sent successfully and which ones need to be retransmitted. 

Regarding claims 8 and 10, Klimenko discloses a media access control (MAC) address of 
the NIC that is 12 characters long in hexidecimal format, or 6 bytes long if represented in binary 
(col. 10, line 5). The server also has a MAC address (col. 1 1, lines 35-37). Klimenko fails to 
disclose a system frame header that specifies the addresses of the router card and system 
controller. RFC 783 discloses a system frame header composed of Local Medium and Internet 
headers (Figure 3-1, page 5). At the time the invention was made, it would have been obvious to 
send the MAC addresses of the NIC and server in the Local Medium part of a system frame 
header in the invention of Klimenko. One of ordinary skill in the art would have been motivated 
to do this so that the packet would be routed to the correction destination NIC and that the 
receiving NIC was sure that this packet was coming from the server. 

Regarding claims 11, 12, 39, 42, 44 and 47, Klimenko discloses a media access control 
(MAC) address of the NIC that is 12 characters long in hexidecimal format, or 6 bytes long if 
represented in binary (col. 10, line 5). The server also has a MAC address (col. 1 1, lines 35-37). 
Klimenko fails to disclose a system frame header that specifies the addresses of the router card 
and system controller, a request code, and a file type in the request packet. RFC 783 discloses a 
system frame header composed of Local Medium and Internet headers (Figure 3-1, page 5). 
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RFC 783 also discloses a request packet format that includes an opcode, which is the request 
code of the present invention, and a filename, which represents the file type of the present 
invention (see Figure 5-1, page 8). At the time the invention was made, it would have been 
obvious to send the MAC addresses of the NIC and server in the Local Medium part of a system 
frame header in the invention of Klimenko. It also would have been obvious to include a request 
code and the file type in the request packet. One of ordinary skill in the art would have been 
motivated to do this so that the packet would be routed to the correction destination NIC and that 
the receiving NIC was sure that this packet was coming from the server. One would have been 
motivated to include the request code and file type to be compliant with the TFTP format of a 
request packet. 

Regarding claim 13, Klimenko discloses that the process of downloading a boot file 
occurs after a user has powered-up client PC (10), which includes the NIC (col. 9, lines 56-66). 
It is inherent that if the client PC is powered-up it was at some point previously powered-off. 

Regarding claims 14 and 15, Klimenko discloses that the process of downloading a boot 
file occurs after a user has powered-up client PC (10), which includes the NIC (col. 9, lines 56- 
66). It is inherent that if the client PC is powered-up it was at some point previously powered- 
off. 

Conclusion 

4. Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). 
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A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 

5. Any inquiry concerning this communication, or earlier communications from the 
examiner should be directed to Thomas Volper whose telephone number is 703-305-8405 and 
fax number is 703-746-9467. The examiner can normally be reached between 8:30am and 
6:00pm M-F. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Huy Vu, can be reached at 703-308-6602. Any inquiry of a general nature or relating 
to the status of this application or proceeding should be directed to the receptionist whose 
telephone number is 703-305-4750. 

Thomas E. Volper 
November 18, 2003 
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